There are a few occasions where a statement block might be used inside an expression. One is in C or C++ code using the gcc extension for this, e.g:
1: int res = ({
2: int y = foo (); int z;
3: if (y > 0) z = y; else z = - y;
4: z;
5: });
Lines 2 and 5 get the
inexpr-statement syntax, besides the symbols they'd
get in a normal block. Therefore, the indentation put on
inexpr-statement is added to the normal statement
block indentation. An inexpr-statement syntactic
element doesn't contain an anchor position.
In Pike code, there are a few other situations where blocks occur inside statements, as illustrated here:
1: array itgob()
2: {
3: string s = map (backtrace()[-2][3..],
4: lambda
5: (mixed arg)
6: {
7: return sprintf ("%t", arg);
8: }) * ", " + "\n";
9: return catch {
10: write (s + "\n");
11: };
12: }
Lines 4 through 8
contain a lambda function, which CC Mode recognizes by the
lambda keyword. If the function argument list is put
on a line of its own, as in line 5, it gets the
lambda-intro-cont syntax. The function body is
handled as an inline method body, with the addition of the
inlambda syntactic symbol. This means that line 6
gets inlambda and inline-open, and line
8 gets inline-close1.
On line 9,
catch is a special function taking a statement block
as its argument. The block is handled as an in-expression
statement with the inexpr-statement syntax, just
like the gcc extended C example above. The other similar special
function, gauge, is handled like this too.
[1] You might wonder why it doesn't get
inlambda too. It's because the closing brace is
relative to the opening brace, which stands on its own line in
this example. If the opening brace was hanging on the previous
line, then the closing brace would get the
inlambda syntax too to be indented correctly.